AI and machine learning are seemingly everywhere, and that’s forcing every database company to think about vector search. Companies want to build things like smart search that actually understands what you mean, recommendation systems that know what you’ll like, and tools that can spot when something’s off. To make all of this work at the scale they need, they’re realizing their databases have to be able to handle vectors, not just regular data.
MySQL wasn’t designed with vectors in mind, but that certainly hasn’t slowed interest. PostgreSQL (with pgvector) and MongoDB already deliver production-ready options, while MySQL providers are still exploring what the future should look like. At Percona, we’re asking a simple question:
Should vector search become part of the MySQL experience?
Your input will help us decide.
Why your voice matters
We know there’s real interest in this space, but we want to understand how important MySQL vector capabilities are for you. Would you use them in production? Which use cases matter most? How soon would this become relevant for your projects?
Your input will help us answer key questions, including:
- Which workloads would benefit most from vector search in MySQL?
- How critical are features like real-time access, transactional consistency, or simplified architecture?
- What would make MySQL a competitive choice for enterprises running AI/ML applications?
Share your perspective on vector search in MySQL
The survey only takes a few minutes, but your feedback will carry real weight. Whether you’re a developer, DBA, data scientist, or IT leader, we’d love to hear from you.
I appreciate Percona taking a survey-driven approach rather than rushing to add vector search capabilities just because competitors have them. The timing of this question is crucial—MySQL is at an interesting inflection point.
A few considerations worth highlighting:
Architecture matters: One key advantage MySQL could offer is transactional consistency between vector and relational data in a single system. Many current solutions force developers to maintain separate vector stores (Pinecone, Weaviate) alongside their RDBMS, creating synchronization headaches and eventual consistency issues. If MySQL can offer ACID guarantees across both data types, that’s a genuine differentiator.
Performance trade-offs: The real question isn’t just “can MySQL do vectors?” but “should it?” Vector operations (approximate nearest neighbor search) have very different performance characteristics than traditional B-tree queries. Will this be an optional extension, a storage engine, or core functionality? Each choice has implications for maintenance overhead and query optimization.
Ecosystem integration: PostgreSQL’s success with pgvector partly stems from its rich extension ecosystem and flexibility. MySQL would need to consider how vector search integrates with existing tools, replication architectures, and the InnoDB storage engine—or whether an alternative engine makes more sense.
The real test will be latency and scalability benchmarks compared to purpose-built vector databases. For many use cases, “good enough” integrated vector search beats “optimal” separate infrastructure due to reduced operational complexity.
Looking forward to seeing how the survey results shape this decision.